The timeout is not cleared when the LLM call completes first, which can lead to resource leaks. The existing CommitMsgHandler pattern (lines 165-175 in src/application/handlers/CommitMsgHandler.ts) stores the timeoutId and calls clearTimeout after the Promise.race completes. This implementation should follow the same pattern to prevent the timeout callback from executing unnecessarily.

The constructor throws a generic Error instead of a domain-specific error. The existing AnthropicLLMClient uses LLMError (imported from '../../domain/errors/LLMError') when the API key is missing. For consistency, IntentExtractor should either use LLMError or create a similar domain error class.

Missing documentation constraint. Following the pattern established for enrichTimeout (line 58 in IHookConfig.ts: "Must be under hook timeout (10s)"), this field should include the same constraint documentation since it's also used within the hook's 10-second hard timeout.

No unit tests exist for IntentExtractor, despite the presence of comprehensive test coverage for AnthropicLLMClient (258 lines in tests/unit/infrastructure/llm/AnthropicLLMClient.test.ts). Tests should cover: constructor validation (API key handling), minWords threshold logic, confirmation pattern matching, timeout behavior, LLM skip response handling, and error cases.

Design mismatch: IntentExtractor accepts timeout and minWords in the constructor (lines 20-23, 52-53), but the DI container creates it without config (line 121-124 doesn't pass these options). Unlike llmClient which accepts config per-call, IntentExtractor's config is fixed at construction. Since hook config is only available at runtime in handlers (see CommitMsgHandler line 48-49 pattern), the configured values (intentTimeout, minWords from IPromptSubmitConfig) cannot be used. Either: (1) Add timeout/minWords parameters to the extract() method, or (2) Make intentExtractor a factory function that accepts config.

⚠️ Potential issue | 🟠 Major

#!/bin/bash
# Check for usages of intentTimeout/minWords/extractIntent across the codebase
rg -n --type=ts '\bintentTimeout\b|\bminWords\b|\bextractIntent\b' | head -100

#!/bin/bash
# Also search for IntentExtractor class definition and usage
rg -n --type=ts 'class IntentExtractor|IntentExtractor(' | head -50

#!/bin/bash
# Search for promptSubmit config references
rg -n --type=ts 'promptSubmit' | head -50

#!/bin/bash
# Check the IntentExtractor class definition to see what parameters it accepts
cat -n src/infrastructure/llm/IntentExtractor.ts | head -60

#!/bin/bash
# Check where IntentExtractor is instantiated - look for "new IntentExtractor"
rg -n --type=ts 'new IntentExtractor' -A5

#!/bin/bash
# Check the container.ts file around the intentExtractor registration
cat -n src/infrastructure/di/container.ts | sed -n '100,150p'

#!/bin/bash
# Check how intentExtractor is used in the hooks layer
rg -n --type=ts 'intentExtractor|extractIntent' src/hooks --context=3

#!/bin/bash
# Check if the hook config is passed to the DI container
rg -n --type=ts 'hookConfig|HookConfig' src/infrastructure/di --context=2

#!/bin/bash
# Check the entire container.ts file to see what options are passed in
cat -n src/infrastructure/di/container.ts | head -50

#!/bin/bash
# Check where intentExtractor is actually used (dependencies)
rg -n --type=ts 'intentExtractor|IIntentExtractor' src/application --context=3

#!/bin/bash
# Check PromptSubmitHandler to see how it uses intentExtractor
cat -n src/application/handlers/PromptSubmitHandler.ts | head -100

#!/bin/bash
# Check if hookConfig is somehow passed to PromptSubmitHandler
rg -n --type=ts 'PromptSubmitHandler' src --context=5

#!/bin/bash
# Check if intentExtractor is actually used/injected anywhere in the codebase
rg -n --type=ts 'intentExtractor' src --context=2 | grep -v 'asFunction\|singleton\|test'

#!/bin/bash
# Check if the config values are actually read and used anywhere
rg -n --type=ts 'intentTimeout|minWords' src/infrastructure/di --context=3

#!/bin/bash
# Check all services that depend on intentExtractor in the DI container
cat -n src/infrastructure/di/container.ts | sed -n '50,150p'

#!/bin/bash
# Search for any service that has intentExtractor as a constructor dependency
rg -n --type=ts 'intentExtractor|IIntentExtractor' src/application src/infrastructure/services --context=3

#!/bin/bash
# Check if intentExtractor is ever retrieved from the container after registration
rg -n --type=ts 'container.cradle.intentExtractor' src

Wire intentTimeout and minWords from hook config to IntentExtractor, or remove unused registration.

promptSubmit.intentTimeout and promptSubmit.minWords are defined in config defaults (lines 50-51 in src/hooks/utils/config.ts), and IntentExtractor accepts these as timeout and minWords options. However, the DI container instantiation (lines 121-124 in src/infrastructure/di/container.ts) passes only apiKey and logger, ignoring the config values. Additionally, intentExtractor is registered in the container but appears unused—no service depends on it or retrieves it via container.cradle.intentExtractor. Either thread the config values through the container and wire them into services that use intentExtractor, or remove the registration if it's not needed.

In `@src/infrastructure/di/container.ts` around lines 114 - 128, The DI
registration for intentExtractor either needs to accept and pass the
promptSubmit config values into IntentExtractor or be removed if unused: update
the intentExtractor asFunction factory to read promptSubmit.intentTimeout and
promptSubmit.minWords from your config (e.g., the same source that defines
promptSubmit defaults) and pass them as timeout and minWords into new
IntentExtractor({ apiKey, logger: container.cradle.logger, timeout:
<intentTimeout>, minWords: <minWords> }), and ensure any service that relies on
intent extraction obtains container.cradle.intentExtractor; alternatively, if no
service consumes container.cradle.intentExtractor, delete the intentExtractor
registration to avoid dead code.